IBIS Macromodel Task Group Meeting date: 31 July 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that he had removed the "Pending BIRDs, expected to be rejected" list from the agenda email. At the last IBIS Open Forum meeting, the 4 BIRDs on that list were all officially rejected. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 24 meeting. Walter moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Upgrading the input thresholds/measurement info to include eye diagram specs: Walter shared and reviewed his "DDR4/DDR5 discussions" email, which was sent to the ATM group after the last meeting. He noted that he intended the email as a summary of the state of discussions on this topic and the "single ended applications of AMI" topic. Walter noted 4 primary issues: 1. Thresholds - Walter noted that this would be resolved with the new keyword proposal discussed at the previous meeting: [Standard] (or something similar). Arpad said he agreed in general, but that details might change. Walter agreed and said this was intended as a high-level overview. 2. Clock Forwarding - Walter suggested that one solution was to use the existing clock_times (pointer) argument in the AMI_GetWave() function signature for passing clock waveforms into the .dll as well as receiving clock ticks back from it. Walter noted that it's not difficult to pass DQS clock waveforms into the Rx GetWave(). He suggested the hard part for IBIS will be documenting how the EDA tool should generate the clock waveforms and how the .dll will consume them. Walter suggested we table this particular issue until we take up a BIRD to deal with the details. Arpad noted that the clock ticks passed back from the .dll are used to assemble the eye diagram. He asked if we would need to send the clock waveforms into the .dll, or if the EDA tool could just process them directly and apply the information. Walter/Ambrish noted the Rx might have a DFE. Walter noted that it might not be clear how the phase between clock and data would be determined inside the model. In DDR4 there is a training process to determine that phase. Arpad asked how that clock waveform would be passed in to the .dll. Ambrish said it could be passed in using the same format that the data waveform uses (data waveform is passed in using the "wave" pointer argument). Walter noted that we would want this to work for DDR5 writes, which are controlled by the JEDEC DDR5 standard. But, we probably also want to run simulations for DDR5 reads, and there is no specification for what the controller does in that case. Walter noted his conversation with Steve Parker (see notes for previous meeting), and noted that there might buses other than DDR5 for which this would be applicable. He had suggested that Steve could write a BIRD himself or ask IBIS to add this feature. Walter said we needed someone to take up a BIRD. Ambrish noted that he had proposed writing a BIRD to address clock forwarding and the floating Vref, and he said he would check back with his co-workers. 3. Floating Vref - Walter noted that IBIS's existing Vinl and Vinh might not be very meaningful for this since they are absolute quantities. Walter noted that the standard would define this, so the [Standard] keyword would address this issue. The standard would say that it's a floating Vref, and the EDA tool would adjust the offset accordingly to find the VREFDQ that yields the best eye opening. One metric is the widest eye; another is the largest eye mask margins. Randy noted that it might be useful to have the Vref value that is calculated by the tool be passed into the AMI model. Walter agreed, and noted that since the AMI model uses an impulse response it knows nothing about the DC level. Walter said it might be useful to add a new Reserved Parameter for that purpose. Randy noted that this might be part of the BIRD Ambrish/Walter had just discussed. Fangyi asked how Vref would be used if it were passed into the model. Randy said you could potentially use it to look up different tables describing CTLE behavior. There are certain things being modeled that could be sensitive to the Vref level. Arpad asked if Vref would be provided once at the beginning of the simulation, or if it needed to be continuously updated. Randy noted that Vref is generated inside the DRAM, but they model it by having the system specify what that Vref level is and assume that's what's being used in the VRAM. Arpad asked if it would be generated once or continuously updated based on noise, temp, etc. Walter said that it would be calculated once, and it's typically the midpoint between the initial and final values of the step response (which is the same for a rising or falling step response). Fangyi noted that this raised an interesting question. What is the input signal to the Rx GetWave() function in this scenario? Is it differential or single ended? Walter noted that this was a good question, and the tool could make the waveform input to the Rx GetWave() either way. The waveform could be centered about Vref, or it could be centered about 0 with the Vref offset kept track of separately. Ambrish asked if it mattered to the .dll. Fangyi said yes, that DFE would care about the threshold. Walter noted that removing the Vref (waveform centered about zero), allowed the AMI block to operate as differential and the bias could be added back later. Ambrish noted that the threshold could be calculated dynamically. Fangyi agreed, and said this was why he had asked his first question about what the model would use for the Vref (how it would be used if Vref were passed in via a Reserved parameter). If we had a single ended signal with a DC bias, then perhaps the model could use a Vref passed in, or internally generate the Vref if it were passed the single ended waveform including the bias. Fangyi noted that we could even change the specification for the input to the Tx GetWave(), so it would no longer have to be differential. Walter agreed that there were many possible approaches. Walter noted that he thought it was not necessary to make many changes, and that we could say that for the AMI modeling and processing you're centered about zero and handle the bias separately. Fangyi said he thought it might be better if the waveform passed to GetWave() represented the actual signal as much as possible. If the signal has a DC bias, then the waveform should probably have that bias. Fangyi said that this would likely make life easier for the model makers. They likely have a block that detects the threshold voltage, and they could just convert that block into an AMI model. Otherwise, if we gave them a differential signal, the model maker would have to remove that threshold block when they created their model. Walter noted that these were all good points for a detailed discussion. Walter noted that the bias issue is simple to handle. - We could strip out the bias and leave the AMI processing with zero-centered waveforms. OR - We could handle it with a Vref Reserved parameter and pass the single-ended waveform containing the bias to the GetWave(). The model could then use the Vref Reserved parameter or compute the bias itself. 4. Asymmetric rise/fall - Independent of how we handle the bias, Walter posed the question, "How do we generate the input to the Rx GetWave()?" - We know there is rising/falling asymmetry for DDR5. - Is it possible the effect is small enough to be ignored? - Here we will assume the differences are important. - Can this be handled by the EDA tool without changing the AMI signatures? - Ambrish/Walter say it can be done. - Keysight says the current flows are broken. - Both statements are probably right. - Do we change the API or the flows? - Statistical flow currently says "one" IR represents the systems. - Time Domain flow has the same issue. It says convolve with "the" IR of the channel, which doesn't make sense if you have two impulse responses. Walter noted that we have to assume the EDA vendors have implemented GetWave() flows for DDR5. We have to assume they are all currently different. If we all described the way we create that input to GetWave(), then we could see if we agree enough to write a BIRD. But, if one disagrees then they wouldn't be happy with the BIRD. Fangyi said the question went beyond whether we change AMI function signatures or the flows. The question is more fundamental. Are the basic assumptions of AMI valid? AMI assumes the channel is LTI so we can partition the channel and do convolution. The fact that the rising/falling edges have asymmetry indicates that this system is not LTI. The system response depends on the signal if rising edges and falling edges have different system responses. Walter agreed that it's not strictly LTI. The interconnects are certainly LTI, but the driver is not because of the rise/fall asymmetry. Can we somehow meld the rising and falling step responses into a single impulse response? If you just use the rising step response (typically slower edge rate) you get an answer that is too pessimistic. If you just use the falling step response you get an answer that is too optimistic. If you "average" them out, you get an answer that does a decent job predicting the performance of the channel. Radek noted that because of the non-linearities even the rising step response you compute may not reflect what's happening for a different signal. Ambrish said that the solution they implemented was transparent to both the user and the AMI model. So, they didn't think footprint or flow changes were needed. The flows are just sample flows for differential SerDes. It's okay to have a different flow that integrates the rise/fall asymmetry. Fangyi said the validity of the entire AMI modeling technique is questionable for this application. Walter said if we think primarily about DDR5 writes, where we know the Rx has DFE (the JEDEC standard doesn't really define what's in the controller for equalization, so we don't what the Tx eq is for writes or the Rx eq is for reads), we can ask the question, "Can we get an answer from AMI simulation that is good enough to make engineering decisions?". Can AMI correlate well enough with measurements or full transistor simulations? He and Ambrish believe that you can get there with AMI modeling techniques. There are ways to do it with Init() flows that give you reasonable answers, and there are ways to do it with GetWave() that produce extremely good waveforms for Rx GetWave() that capture the rising/falling asymmetry and downstream reflection effects. No modeling is perfect, but can the existing AMI footprint and methodology give engineers useful tools? Ambrish and Walter say yes. Fangyi and Radek aren't so sure. Walter suggested we might consider having a multi-vendor panel discussion at DesignCon. Others noted their hope that we would make progress long before then. Arpad asked if we could consider SSO effects too, if we were going to consider modifying AMI. Walter noted there are two parts to SSO, crosstalk and power delivery effects. AMI can handle crosstalk, and currently EDA tools could model some power effects but it's totally incompatible with AMI itself. - Mike L.: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 07 August 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives